Specifying levels of access to a thread entity in a multithreaded environment

ABSTRACT

Techniques are disclosed for providing thread specific protection levels in a multithreaded processing environment. An associated method includes generating a group of threads in a process, one of the group of threads opening a thread entity, and that one of the group of threads specifying one or more levels of access to the thread entity for the other threads. In one embodiment, when a first of the threads attempts to perform a specified operation on the thread entity, the method includes determining whether that first thread is the one of the group of threads that opened the thread entity. When the first thread is not that one of the group of threads, the first thread is allowed to perform the specified operation if and only if such operation is permitted by the specified one or more levels of access.

TRADEMARKS

IBM® is a registered trademark of International Business MachinesCorporation, Armonk, N.Y., U.S.A. Other names used herein may beregistered trademarks, trademarks, or product names of InternationalBusiness Machines Corporation or other companies. Microsoft® andWindows® are registered trademarks of Microsoft Corporation.

BACKGROUND

Multi processor computer systems have become commonplace in the last fewyears. In these systems, a process is separated into componentinstruction sequences, referred to as threads that are processedconcurrently by the multiple processors. In some computer systems suchas the BluGene computer system developed by the International BusinessMachines Corporation (IBM), there may be many thousands of threadsexecuting at the same time. Even in the more traditional computersystems such as the eServer iSeries developed by IBM, some Websphereapplications may have many hundreds of threads.

In a multithreaded environment any thread can operate on a file/socketdescriptor (referred to herein as “thread entities”) opened by a parentthread. There are scenarios where a file or a socket opened by onethread is inadvertently closed or its contents corrupted by some otherthread. There are no known solutions for this issue as all the threadsin a process share the same thread entities, which are global. It wouldbe beneficial in some embodiments to provide a mechanism to amelioratethe above mentioned scenarios by specifying protection levels on threadentities created by parent threads.

SUMMARY

An embodiment provides a method, system, and computer program productfor providing thread specific protection levels in a multithreadedprocessing environment. The method includes generating a group ofthreads in a process, one of the groups of threads opening a threadentity, and the one of the group of threads specifying one or morelevels of access to the thread entity for the others of the group ofthreads.

In one embodiment, the method further includes a first of the group ofthreads attempting to perform a specified operation on the threadentity, and determining whether the first of the group of threads is theone of the group of threads. In this embodiment, when the first of thegroup of threads is the one of the group of threads, the first of thegroup of threads performs the specified operation. When the first of thegroup of threads is not the one of the group of threads, the first ofthe group of threads performs the specified operation if and only if thespecified operation is permitted by the specified one or more levels.

These specified levels of thread access include, for example, a firstlevel that allows the other threads read only access to the threadentity, a second level that allows the other threads write only accessto the thread level, a third level that allows the other threads onlyread and write access to the thread entity. These levels of access mayfurther include a fourth level that allows the other threads no accessto the thread entity, and a fifth level that allows the other threadsread and write access to the thread entity but prohibits any of theseother threads from closing the thread entity.

With this disclosure, any thread inside a process can specify a level ofprotection on the thread entities when the thread opens those entities.The thread may specify whether other threads in process can write/readfrom the thread entity, other threads are denied write/read access tothe thread entity, or other threads can read/write but cannot close thisthread entity. Also, the thread can omit this option completely, therebyreverting to the normal behavior, providing complete access to threadentity.

The thread may also decide to set these thread entity protection levels(TEPL) at a later stage through a system call interface provided forthis purpose, but the thread is allowed to set restrictions only onthread entities previously opened by the thread.

Further benefits and advantages of this invention will become apparentfrom a consideration of the following detailed description, given withreference to the accompanying drawings, which specify and show preferredembodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an exemplary representation of a data processing system thatmay be used to implement embodiments of the invention.

FIG. 2 is an exemplary embodiment of a block diagram of a dataprocessing system in which embodiments of the invention may beimplemented.

FIG. 3 illustrates an exemplary embodiment of a mechanism fordispatching threads in a multi-processor computing system.

FIG. 4 shows an exemplary embodiment of the control flow when anembodiment of the invention is enabled and used in a computing system.

DETAILED DESCRIPTION

Reference will now be made in detail to the subject matter disclosed,which is illustrated in the accompanying drawings. It will be readilyunderstood that the components of the embodiments of the invention, asgenerally described and illustrated in the figures herein, may bearranged and designed in a wide variety of different configurations inaddition to the described exemplary embodiments. Thus, the followingmore detailed description of the embodiments of the invention, asrepresented in the figures, is not intended to limit the scope of thedisclosure, as claimed, but is merely representative of the embodimentsof the invention.

Furthermore, the described features, structures, or characteristics maybe combined in any suitable manner in one or more embodiments. In thefollowing description, numerous specific details are provided to give athorough understanding of embodiments of the invention. One skilled inthe relevant art will recognize, however, that the various embodimentsof the invention can be practiced without one or more of the specificdetails, or with other methods, components, materials, etc. In otherinstances, well-known structures, materials, or operations are not shownor described in detail to avoid obscuring aspects of the embodiments ofthe invention. The illustrated embodiments of the invention will be bestunderstood by reference to the drawings. The following description isintended only by way of example and simply illustrates certain selectedexemplary embodiments of the invention as claimed herein.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which includes one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

As will be appreciated by one skilled in the art, embodiments of theinvention may be presented as a system, method or computer programproduct. Accordingly, embodiments of invention may take the form of anentirely hardware embodiment, an entirely software embodiment (includingfirmware, resident software, micro-code, etc.) or an embodimentcombining software and hardware aspects that may all generally bereferred to herein as a “circuit,” “module” or “system.” Furthermore,the embodiments of the invention may take the form of a computer programproduct embodied in any tangible medium of expression having computerusable program code embodied in the medium.

Any combination of one or more computer usable or computer readablemedium(s) may be utilized. The computer-usable or computer-readablemedium may be, for example but not limited to, an electronic, magnetic,optical, electromagnetic, infrared, or semiconductor system, apparatus,device, or propagation medium. More specific examples (a non-exhaustivelist) of the computer-readable medium would include the following: anelectrical connection having one or more wires, a portable computerdiskette, a hard disk, a random access memory (RAM), a read-only memory(ROM), an erasable programmable read-only memory (EPROM or Flashmemory), an optical fiber, a portable compact disc read-only memory(CDROM), an optical storage device, a transmission media such as thosesupporting the Internet or an intranet, or a magnetic storage device.Note that the computer-usable or computer-readable medium could even bepaper or another suitable medium, upon which the program is printed, asthe program can be electronically captured, via, for instance, opticalscanning of the paper or other medium, then compiled, interpreted, orotherwise processed in a suitable manner, if necessary, and then storedin a computer memory.

In the context of this disclosure, a computer-usable orcomputer-readable medium may be any medium that can contain, store,communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, or device.The computer-usable medium may include a propagated data signal with thecomputer-usable program code embodied therewith, either in baseband oras part of a carrier wave. The computer usable program code may betransmitted using any appropriate medium, including but not limited towireless, wireline, optical fiber cable, RF, etc.

Computer program code for carrying out operations of the presentinvention may be written in any combination of one or more programminglanguages, including an object oriented programming language such asJava, Smalltalk, C++ or the like and conventional procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The program code may execute entirely on the user's computer,partly on the user's computer, as a stand-alone software package, partlyon the user's computer and partly on a remote computer or entirely onthe remote computer or server. In the latter scenario, the remotecomputer may be connected to the user's computer through any type ofnetwork, including a local area network (LAN) or a wide area network(WAN), or the connection may be made to an external computer (forexample, through the Internet using an Internet Service Provider).

Embodiments of the invention are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products. It will be understood that eachblock of the flowchart illustrations and/or block diagrams, andcombinations of blocks in the flowchart illustrations and/or blockdiagrams, can be implemented by computer program instructions. Thesecomputer program instructions may be provided to a processor of ageneral purpose computer, special purpose computer, or otherprogrammable data processing apparatus to produce a machine, such thatthe instructions, which execute via the processor of the computer orother programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer program instructions may also bestored in a computer-readable medium that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablemedium produce an article of manufacture including instruction meanswhich implement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer implemented process such that theinstructions which execute on the computer or other programmableapparatus provide processes for implementing the functions/actsspecified in the flowchart and/or block diagram block or blocks.

With reference now to the figures and in particular with reference toFIG. 1, an exemplary representation of a data processing system in whichembodiments of the invention may be implemented is depicted. A computer100 is depicted which includes system unit 102, video display terminal104, keyboard 106, storage devices 108, which may include floppy drivesand other types of permanent and removable storage media, and mouse 110.Additional input devices may be included with computer 100, such as, forexample, a joystick, touchpad, touch screen, trackball, microphone, andthe like. Computer 100 can be implemented using any suitable computer,such as an IBM eServer computer or IntelliStation computer, which areproducts of International Business Machines Corporation, located inArmonk, N.Y. Although the depicted representation shows a computer,other embodiments of the present invention may be implemented in othertypes of data processing systems, such as a network computer. Computer100 also preferably includes a graphical user interface (GUI) that maybe implemented by means of systems software residing in computerreadable media in operation within computer 100.

With reference now to FIG. 2, an exemplary embodiment of a block diagramof a data processing system is shown in which embodiments of theinvention may be implemented. Data processing system 200 is an exampleof a computer, such as computer 100 in FIG. 1, in which code orinstructions implementing the processes of the present invention may belocated. Data processing system 200 employs a peripheral componentinterconnect (PCI) local bus architecture. Although the depicted exampleemploys a PCI bus, other bus architectures such as Accelerated GraphicsPort (AGP) and Industry Standard Architecture (ISA) may be used.

Processor system 202 and main memory 204 are connected to PCI local bus206 through PCI bridge 208. PCI bridge 208 also may include anintegrated memory controller and cache memory for processor system 202.Processor system 202 is representative of a multiple processor systemhaving two or more multi-processor modules such as a dual-processormodule, a multi-processor module, or dual or multi-SMT processors.Additional connections to PCI local bus 206 may be made through directcomponent interconnection or through add-in connectors. In the depictedexample, local area network (LAN) adapter 210, small computer systeminterface SCSI host bus adapter 212, and expansion bus interface 214 areconnected to PCI local bus 206 by direct component connection. Incontrast, audio adapter 216, graphics adapter 218, and audio/videoadapter 219 are connected to PCI local bus 206 by add-in boards insertedinto expansion slots. Expansion bus interface 214 provides a connectionfor a keyboard and mouse adapter 220, modem 222, and additional memory224. SCSI host bus adapter 212 provides a connection for hard disk drive226, tape drive 228, and CD-ROM drive 230. Typical PCI local busimplementations will support three or four PCI expansion slots or add-inconnectors.

An operating system runs on processor system 202 and is used tocoordinate and provide control of various components within dataprocessing system 200 in FIG. 2. The operating system may be acommercially available operating system such as Windows XP, which isavailable from Microsoft Corporation. An object oriented programmingsystem such as Java may run in conjunction with the operating system andprovides calls to the operating system from Java programs orapplications executing on data processing system 200. “Java” is atrademark of Sun Microsystems, Inc. Instructions for the operatingsystem, the object-oriented programming system, and applications orprograms are located on storage devices, such as hard disk drive 226,and may be loaded into main memory 204 for execution by processor system202.

Those of ordinary skill in the art will appreciate that the hardware inFIG. 2 may vary depending on the implementation. Other internal hardwareor peripheral devices, such as flash read-only memory (ROM), equivalentnonvolatile memory, or optical disk drives and the like, may be used inaddition to or in place of the hardware depicted in FIG. 2.

For example, data processing system 200, if optionally configured as anetwork computer, may not include SCSI host bus adapter 212, hard diskdrive 226, tape drive 228, and CD-ROM 230. In that case, the computer,to be properly called a client computer, includes some type of networkcommunication interface, such as LAN adapter 210, modem 222, or thelike. As another example, data processing system 200 may be astand-alone system configured to be bootable without relying on sometype of network communication interface, whether or not data processingsystem 200 includes some type of network communication interface. Thedepicted example in FIG. 2 and above-described examples are not meant toimply architectural limitations. The processes of the present inventionare performed by processor system 202 using computer implementedinstructions, which may be located in a memory such as, for example,main memory 204, memory 224, or in one or more peripheral devices226-230.

FIG. 3 is an exemplary diagram of a multi-processor system 300 in whichan embodiment of the invention may be implemented. MP system 300 is anexample of a data processing system, such as data processing system 200in FIG. 2. As shown in FIG. 3, MP system 300 includes dispatcher 350 anda plurality of processors 320-323. Dispatcher 350 assigns threads toprocessors in system 300. Although dispatcher 350 is shown as a singlecentralized element, dispatcher 350 may be distributed throughout MPsystem 300. For example, dispatcher 350 may be distributed such that aseparate dispatcher is associated with each processor 320-323 or a groupof processors, such as processor deployed on a common chip. Furthermore,dispatcher 350 may be implemented as software instructions run onprocessor 320-323 of the MP system 300.

Micro processor system 300 may be any type of system having a pluralityof multi-processor modules. As used herein, the term “processor” refersto either a central processing unit or a thread processing core of anSMT processor. Thus, a multi-processor module is a processor modulehaving a plurality of processors, or (CPUs), deployed on a single chip,or a chip having a single CPU capable of simultaneous execution ofmultiple threads, e.g., an SMT CPU or the like. In the illustrativeexample, processors 320 and 321 are deployed on a single multi-processormodule 310, and processors 322 and 323 are deployed on a singlemulti-processor module 311. As referred to herein, processors on asingle multi-processor module, or chip, or said to be adjacent. Thus,processors 320 and 321 are adjacent, as are processors 322 and 323.

In a multithreaded environment, whenever a file/socket is opened, anyother thread in the process can access the thread entities. Embodimentsof the invention provide a way for a thread to provide specificprotection levels to other threads in the process of accessing thethread entities. This can be achieved by providing special flags, whichcan be used during the file or socket open calls.

For example, in one embodiment, an open call with Thread EntityProtection Levels (TEPL) looks like:th_open(<filename>,O_CREAT|O_TEPL_RDONLY).

When the above call is executed, the thread identifier (ID) of thecurrent thread (hence parent thread for this thread entity) is stored inan appropriate structure (for example, a UNIX file descriptor table),along with the O_TEPL_RDONLY permission level for the opened entity. Nowthe other threads can only perform read operation on this entity.

In a further embodiment, a thread entity can have one of the followingpermissions:

O_TEPL_RDONLY Other threads are allowed only to read O_TEPL_WRONLY Otherthreads are allowed only to write O_TEPL_RDWR Other threads are allowedonly to read/write O_TEPL_EXCL No access allowed to other threadsO_TEPL_NOCLOSE Other threads can read/write but not close this threadentity.

Similarly, the TEPLs can be set using “fcntl” system calls. When fileoperations other than open are performed on a file descriptor (“fd”),the thread ID of the current thread is matched against the stored threadID (parent thread ID) for that “fd”. If they do not match, theoperations continue only when the TEPL flags allow the specifiedoperation. “fcntl” is a standard UNIX system call used to performoperations on a “fd”.

If no TEPLs are specified for the thread entity, then all threads areallowed all permitted operations.

Upon exit of the parent thread, the thread entities that were notexplicitly closed remain open and their parent is set to the Main thread(process), i.e., the Main thread inherits all the TEPLs. For thesethread entities that remain open, the descriptors accessing thefiles/sockets remain unchanged. These thread entities will be cleaned upwhen the process exits.

The serialization of the files/socket read/writes continue to remainunchanged when the O_TEPL_RDONLY/O_TEPL_RDWR or O_TEPL_WRONLY are set.However, the possibility of other threads corrupting the data referencedby the thread entities may be addressed by using the O_TEPL_RDONLY flag,which will allow only read access to threads other than the parentthread. Thus, the parent thread is assured that the thread entity onwhich it is operating will not be corrupted/closed by the other threadsthat merely have read permissions. For example, if the parent threadwants the other threads to log information into a log file but not haveaccess to the contents referenced by the thread entity (to which otherthreads would have also written) or close access to the thread entity,then the parent thread would set the O_TEPL_WRONLY or O_TEPL_NOCLOSEflag, respectively.

Further, the TEPLs can be restricted by using the O_TEPL_EXCL flag,which does not allow access to other threads, thereby avoiding anysynchronization issues such as read after write/read before write withrespect to the other threads.

Embodiments of the invention address the scenario in which other threadsclose the thread entities created by the parent thread inadvertently.Such scenario can cause the parent thread to behave unexpectedly andeven terminate depending on the nature of its operation. The flagO_TEPL_NOCLOSE provides read/write access to other threads but does notallow other threads to close the thread entity opened by the parentthread.

The TEPL should agree with the file open mode privilege. i.e., a fileopened in read mode can only have its TEPLs set to O_TEPL_RDONLY,O_TEPL_EXCL, O_TEPL_NOCLOSE and not O_TEPL_WRONLY or O_TEPL_RDWR.

The special descriptor's STDIN, STDOUT and STDERR by default can beaccessed by all the threads inside a process, and if needed, the Mainthread can set TEPLs like O_TEPL_NOCLOSE, thereby preventing otherthreads from closing them inadvertently.

FIG. 4 shows an exemplary embodiment of the flow of control when TEPL isenabled. TEPL checks will be enforced in the thread library 410. Sincethe TEPL check is not made in the file system layer, the thread librarywill need access to the file descriptor table 420 to know the TEPLs 430of the thread entity and the owner thread ID.

In a further embodiment, provisions are thus made in logical file systemlayer 440 to export certain functionality, represented at 450, for thethread library to access the stored TEPL and thread ID values that wereearlier stored along with file descriptor table.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. The corresponding structures, features, materials, acts, andequivalents of all means or step plus function elements in the claimsbelow are intended to include any structure, material, or act forperforming the function in combination with other claimed elements asspecifically claimed.

While it is apparent that embodiments of the invention herein disclosedis well calculated to fulfill the objects stated above, it will beappreciated that numerous modifications and embodiments may be devisedby those skilled n the art, and it is intended that the appended claimscover all such modifications and embodiments as fall within the spiritand scope of this invention.

1. A method comprising: generating a group of threads in a process; opening a thread entity for a first thread among the group of threads, wherein the thread entity is one of a file descriptor and a socket descriptor; and specifying, in agreement with an associated open mode privilege, one or more levels of access to the thread entity for all other threads among the group of threads.
 2. The method of claim 1, further comprising: upon determining that the first thread is attempting to perform a specified operation on the thread entity, allowing the first thread to perform the specified operation.
 3. (canceled)
 4. The method of claim 2, further comprising: upon determining that a second thread among the group of threads is attempting to perform the specified operation, determining whether the specified operation is allowed by the specified one or more levels of access; and upon determining that the specified operation is allowed by the specified one or more levels of access, allowing the second thread to perform the specified operation.
 5. The method of claim 1, wherein each thread among the group of threads has a respective thread identifier (ID), and wherein the method further comprises storing in a table the thread ID of the first thread.
 6. The method of claim 5, further comprising: upon determining that a certain thread among the group of threads is attempting to perform a specified operation on the thread entity, determining whether the thread ID of the certain thread matches the thread ID of the first thread stored in the table; and upon determining that the thread ID of the certain thread matches the thread ID of the first thread, allowing the certain thread to perform the specified operation.
 7. (canceled)
 8. The method of claim 6, further comprising: upon determining that the thread ID of the certain thread does not match the thread ID of the first thread, determining whether the specified operation is allowed by the specified one or more levels of access; and upon determining that the specified operation is allowed by the specified one or more levels of access, allowing the certain thread to perform the specified operation.
 9. The method of claim 1, wherein the one or more levels of access are selected from a group comprising a first level that permits read only access to the thread entity and a second level that permits write only access to the thread entity.
 10. The method of claim 1, wherein the one or more levels of access include a level that prohibits access to the thread entity.
 11. The method of claim 1, wherein the one or more levels of access include a level defined to allow read and write access to the thread entity but to prohibit closure of the thread entity.
 12. A system comprising: a processor; and a memory storing a program, which, when executed on the processor, performs an operation comprising: generating a group of threads in a process; opening a thread entity for a first thread among the group of threads, wherein the thread entity is one of a file descriptor and a socket descriptor; and specifying, in agreement with an associated open mode privilege, one or more levels of access to the thread entity for all other threads among the group of threads.
 13. The system of claim 12, wherein the operation further comprises: upon determining that the first thread is attempting to perform a specified operation on the thread entity, allowing the first thread to perform the specified operation.
 14. (canceled)
 15. The system of claim 13, wherein the operation further comprises: upon determining that a second thread among the group of threads is attempting to perform the specified operation, determining whether the specified operation is allowed by the specified one or more levels of access; and upon determining that the specified operation is allowed by the specified one or more levels of access, allowing the second thread to perform the specified operation.
 16. The system of claim 12, wherein each of the group of threads has a respective thread identifier (ID), and wherein the operation further comprises storing in a table the thread ID of the first thread.
 17. The system of claim 12, wherein the one or more levels of access include a level defined to allow read and write access to the thread entity but to prohibit closure of the thread entity.
 18. A computer program product comprising a non-transitory computer usable medium having computer usable program code embodied therewith, the computer usable program code configured for: generating a group of threads in a process; opening a thread entity for a first thread among the group of threads, wherein the thread entity is one of a file descriptor and a socket descriptor; and specifying, in agreement with an associated open mode privilege, one or more levels of access to the thread entity for all other threads among the group of threads.
 19. The computer program product of claim 18, wherein the computer usable program code is further configured for: upon determining that the first thread is attempting to perform a specified operation on the thread entity, allowing the first thread to perform the specified operation.
 20. The computer program product of claim 18, wherein each of the group of threads has a respective thread identifier (ID), and wherein the computer usable program code is further configured for storing in a table the thread ID of the first thread.
 21. The computer program product of claim 20, wherein the computer usable program code is further configured for: upon determining that a certain thread among the group of threads is attempting to perform a specified operation on the thread entity, determining whether the thread ID of the certain thread matches the thread ID of the first thread stored in the table; and upon determining that the thread ID of the certain thread matches the thread ID of the first thread, allowing the certain thread to perform the specified operation.
 22. The computer program product of claim 21, wherein the computer usable program code is further configured for: upon determining that the thread ID of the certain thread does not match the thread ID of the first thread, determining whether the specified operation is allowed by the specified one or more levels of access; and upon determining that the specified operation is allowed by the specified one or more levels of access, allowing the certain thread to perform the specified operation.
 23. The computer program product of claim 18, wherein the one or more levels of access include a level defined to allow read and write access to the thread entity but to prohibit closure of the thread entity. 